<html>
<head><meta charset="utf-8"><title>current status 06/09 · t-compiler/wg-polymorphization · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/216091-t-compiler/wg-polymorphization/index.html">t-compiler/wg-polymorphization</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/216091-t-compiler/wg-polymorphization/topic/current.20status.2006.2F09.html">current status 06/09</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="209226960"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216091-t-compiler/wg-polymorphization/topic/current%20status%2006/09/near/209226960" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> davidtwco <a href="https://rust-lang.github.io/zulip_archive/stream/216091-t-compiler/wg-polymorphization/topic/current.20status.2006.2F09.html#209226960">(Sep 06 2020 at 14:09)</a>:</h4>
<p>Wanted to drop a message here to update everyone on the current status of polymorphization are and what I think the next steps are.</p>
<p>I think the initial goal ought to be getting polymorphization enabled by default:</p>
<ul>
<li><a href="https://github.com/rust-lang/rust/issues/75185">#75185</a> was opened to perform a crater run on polymorphization enabled-by-default. This was rebased after some other PRs broke polymorphization and we didn't notice, and we've yet to rebase and re-queue it.</li>
</ul>
<p>We've currently got the following open PRs:</p>
<ul>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75675">#75675</a> (assigned to <span class="user-mention" data-user-id="119009">@eddyb</span>) was opened to adjust the new symbol mangling scheme to encode impl parameters - this is an alternative fix for <a href="https://github.com/rust-lang/rust/issues/75326">#75326</a> (which was originally resolved by <a href="https://github.com/rust-lang/rust/issues/75518">#75518</a> and then <a href="https://github.com/rust-lang/rust/issues/75595">#75595</a> - which changed polymorphization's analysis to mark more parameters are used). It's works but one of the tests required normalization that didn't differ based on bitness, which was unexpected and we've yet to decide how to proceed.</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75737">#75737</a> (blocked, but approved by <span class="user-mention" data-user-id="119009">@eddyb</span>)  was opened to remove the predicate logic in polymorphization's analysis. This logic was added during the original polymorphization PR (and then extended in <a href="https://github.com/rust-lang/rust/issues/75518">#75518</a> and <a href="https://github.com/rust-lang/rust/issues/75595">#75595</a>) and isn't necessary after <a href="https://github.com/rust-lang/rust/issues/75675">#75675</a> (which is why it is blocked). Other changes to polymorphization must have affected the necessity of this logic, since I'm confident that the new symbol mangling scheme wasn't the original impetus for it, but I'm not sure which changes those would have been.</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75414">#75414</a> (assigned to <span class="user-mention" data-user-id="119009">@eddyb</span>) changes polymorphization's analysis to take an <code>InstanceDef</code>, which enables the MIR of shims to be polymorphized. I'm not sure if it is exactly what we want.</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75346">#75346</a> (assigned to <span class="user-mention" data-user-id="116009">@nikomatsakis</span>) changes how <code>FnPtrShim</code>s are constructed so that they don't require substitution during codegen - this will help avoid double substitution from polymorphization changes.</p>
</li>
</ul>
<p>We've also got the following issues open:</p>
<ul>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75327">#75327</a> would remove <code>ParamEnv::reveal_all()</code> from codegen, a necessary next step so that we can construct <code>ParamEnv</code>s that constrain generic parameters by their size (eventually) - this is the first step towards polymorphization by size/alignment.</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75336">#75336</a> suggests re-applying some changes from <a href="https://github.com/rust-lang/rust/issues/75255">#75255</a> that we reverted (in <a href="https://github.com/rust-lang/rust/issues/75337">#75337</a>) because it caused regressions (the crux of this issue is fixing those regressions). <a href="https://github.com/rust-lang/rust/issues/75255">#75255</a> modified the closure upvar tuple so that if it contained closures, those would be polymorphized - this was necessary to avoid issues that were revealed when the new symbol mangling scheme was used (<a class="stream-topic" data-stream-id="216091" href="/#narrow/stream/216091-t-compiler.2Fwg-polymorphization/topic/symbol.20mangling.20v0.20.E2.9C.95.20polymorphisation">#t-compiler/wg-polymorphization &gt; symbol mangling v0 ✕ polymorphisation</a> discussed this issue initially). After chatting with eddy, I'm not sure that approach <a href="https://github.com/rust-lang/rust/issues/75255">#75255</a> implemented is desirable - we've experimented with changing how the polymorphization analysis treats closures, and with attempts to reveal other issues that this could be a symptom of - we haven't had any luck with that though. Anyway, the changes that <a href="https://github.com/rust-lang/rust/issues/75336">#75336</a> suggests polymorphizing closures anywhere in a <code>Instance</code>'s substs, not just in the upvar tuple because that would reduce duplication of more functions (see the example in the issue).</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/69925">#69925</a> is fixed by <a href="https://github.com/rust-lang/rust/issues/75346">#75346</a> above.</p>
</li>
<li>
<p><a href="https://github.com/rust-lang/rust/issues/75325">#75325</a> is probably the biggest unknown facing polymorphization right now and relates to how we handle the <code>type_id</code> and <code>type_name</code> intrinsics - which would make polymorphization observable. The issue contains some examples which were failing at one point with polymorphization enabled (I'm not sure if that's still the case). This issue requires a lot of investigation.</p>
</li>
</ul>
<p>I think that's everything. I think that landing the current PRs and addressing <a href="https://github.com/rust-lang/rust/issues/75325">#75325</a> are the most important tasks right now, we can crater after that and hopefully try enabling polymorphization by default.</p>



<a name="209227086"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/216091-t-compiler/wg-polymorphization/topic/current%20status%2006/09/near/209227086" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> davidtwco <a href="https://rust-lang.github.io/zulip_archive/stream/216091-t-compiler/wg-polymorphization/topic/current.20status.2006.2F09.html#209227086">(Sep 06 2020 at 14:12)</a>:</h4>
<p>I'd also be interested in what <span class="user-mention" data-user-id="119009">@eddyb</span> thinks the working group's next steps should be.</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>